_{Reviews (1): Last reviewed commit: "Add official PostHog OpenFeature provide..." | Re-trigger Greptile}

posthog-python Compliance Report

Date: 2026-06-26 21:25:23 UTC
Duration: 530105ms

✅ All Tests Passed!

45/45 tests passed

Capture Tests

✅ 29/29 tests passed

Feature_Flags Tests

✅ 16/16 tests passed

Tested this locally end-to-end against a running PostHog instance (not just the mocked unit/e2e tests) — registered the provider with the OpenFeature SDK and evaluated a real boolean flag through client.get_boolean_details(...), and it worked. 🎉

Repro script I used:

"""
Example demonstrating how to use the PostHog OpenFeature provider.

This example shows:
1. Initializing the PostHog client
2. Registering the PostHogProvider with the OpenFeature SDK
3. Evaluating a boolean feature flag via the OpenFeature API
"""

import os

import posthog
from openfeature import api
from openfeature.evaluation_context import EvaluationContext
from openfeature.contrib.provider.posthog import PostHogProvider

# Initialize the PostHog client
posthog_client = posthog.Posthog(
    project_api_key=os.getenv("POSTHOG_API_KEY", "phc_PIPWvLdxL4N9RUvpyENExMOFEz2jXuk5ehmyXFG3A2k"),
    host=os.getenv("POSTHOG_HOST", "http://localhost:8010"),
)

# Register the PostHog provider with OpenFeature
provider = PostHogProvider(posthog_client)
api.set_provider(provider)

# Get the OpenFeature client
client = api.get_client()

# The flag key to evaluate
flag_key = os.getenv("POSTHOG_FLAG_KEY", "my-flag")

# Evaluation context: targeting_key maps to PostHog's distinct_id
ctx = EvaluationContext(targeting_key="test-user")

# Evaluate the boolean flag
result = client.get_boolean_details(flag_key, False, ctx)

print(f"Flag: {flag_key}")
print(f"Value: {result.value}")
print(f"Reason: {result.reason}")
if result.error_message:
    print(f"Error: {result.error_message}")

posthog_client.shutdown()

(The phc_ key above is a local-dev project key pointing at localhost:8010.) Confirms the full path works as installed: namespace import, provider registration, targeting_key → distinct_id mapping, and the boolean resolution returning the expected value/reason.

_{Reviews (2): Last reviewed commit: "Address review: add missing tests and op..." | Re-trigger Greptile}

since its a new distribution, you'd need to adapt https://github.com/PostHog/posthog-python/blob/main/.github/workflows/release.yml to publish multiple packages
you can check ruby/rails, the js monorepo, etc, since they also publish multiple packages within the release process

Optional nice-to-have: add a CI smoke test that installs the built wheel into a fresh env and imports openfeature.contrib.provider.posthog, since namespace packaging issues are easy to miss with source-tree tests.

The unmatched-user/default behavior should include object flags as well?
- Existing comment covers string/number variant is None.
- resolve_object_details has the same issue when enabled=False and payload=None: it raises TypeMismatchError, so
OpenFeature reports Reason.ERROR / TYPE_MISMATCH instead of a normal default.
- See openfeature-provider/openfeature/contrib/provider/posthog/provider.py:196.
- If they fix non-enrollment handling, apply it consistently to string/number/object and add detail tests checking
no error_code.

left a bunch of comments, main blocker is the release process and a few other comments/suggestions, Phil added good points as well

@marandaneto — implemented your remaining suggestions in 5236b4b:

• Release (release.yml) now publishes openfeature-provider-posthog as a second distribution. Sampo already auto-discovers it as pypi/openfeature-provider-posthog (own pyproject with name + version), and short_tags = "posthog" means it tags as openfeature-provider-posthog-v{version}. The new build/publish/tag steps are gated — they only run when this release actually bumped the provider (a changeset targeting it), so posthog-only releases skip them, and they run after the posthog publish/tag/release so a provider issue can never block the core release.
• Sampo: added openfeature-provider/CHANGELOG.md for it to maintain.
• CI smoke test: the provider job now installs the built wheel into a clean env and imports openfeature.contrib.provider.posthog — catches namespace-packaging regressions source-tree tests miss.
• Pin: posthog>=7.0.0,<8.0.0 (tested major); local-branch build via [tool.uv.sources] was already in place.

One manual prerequisite for the first provider release (can't be done in a PR): register a PyPI trusted publisher for openfeature-provider-posthog pointing at release.yml + the Release environment, exactly like posthog/posthoganalytics. After that, adding a changeset that bumps the provider triggers its first publish.

Verified locally: 37 tests, ruff, mypy, uv build + clean-env wheel install/import all pass; both workflow YAMLs parse. The release flow itself can only be fully exercised on a real release run.

@gustavohstrassburger

Still not fixed / still worth commenting:

1. Provider release/versioning is still broken

   • Release workflow assumes Sampo can process changesets for pypi/openfeature-provider-posthog.
   • But Sampo does not know that package. I verified in a temp worktree:

     sampo add -p pypi/openfeature-provider-posthog -b patch -m test
     # Failed: Package 'pypi/openfeature-provider-posthog' not found in the workspace.

   So openfeature-provider/pyproject.toml won’t be bumped by Sampo, and the release workflow’s detection at
   .github/workflows/release.yml:245 likely never triggers for this package.

2. Provider CI is still only Python 3.12

   • openfeature-provider/pyproject.toml claims Python 3.10–3.14 support.
   • .github/workflows/ci.yml:268-271 still only sets up 3.12.

those are still open, the 2. is optional but i think its cool to test across all major versions like we do for the main package